r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

I think in theory it is possible, at least for sized types, but I am not familiar with how to formally make it so.

r? libs

@EFanZh Is this ready for review? If so, please un-draft the PR.

@joboet: The source code part is mostly done, but I haven’t finished updating LLDB and CDB pretty printers. The CI doesn’t seem to run those tests.

No worries! I just didn't want to keep you waiting in case you had forgotten to change the state.
@rustbot author

For running perf. here, the PR needs to be rebased first.

I’ll fix the conflicts in a few days.

@bors try @rust-timer queue

⌛ Trying commit 817b116 with merge ec7bf66…

To cancel the try build, run the command @bors try cancel.

☀️ Try build successful (CI)
Build commit: ec7bf66 (ec7bf66bfb634dca39e8b1a65c3a872c3cd13fd4, parent: ca77504943887037504c7fc0b9bf06dab3910373)

Finished benchmarking commit (ec7bf66): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 463.988s -> 464.881s (0.19%)
Artifact size: 377.65 MiB -> 377.46 MiB (-0.05%)

@bors try @rust-timer queue

⌛ Trying commit d54c877 with merge 38a5d4f…

To cancel the try build, run the command @bors try cancel.

☀️ Try build successful (CI)
Build commit: 38a5d4f (38a5d4f4c9ded25243c2946db27e12396bfed6a4, parent: 915a766b2f9fd53a8cd7b1fad003d3f8e488ff4b)

Finished benchmarking commit (38a5d4f): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 463.478s -> 463.036s (-0.10%)
Artifact size: 377.38 MiB -> 377.46 MiB (0.02%)

The results here seem to be pretty mixed. Any idea why this seems to hurt some incremental builds? I suppose it could cause more work to do at build time, but the 14% increase building clif seems like something more substantial. Unless, is that code super Arc-heavy or something?

(cranelift-codegen is a benchmark testing building rustc_codgen_cranelift and not a benchmark of the time clif takes to do codegen, right?)

Those icount results look entirely mergeable to me, at least. Notably, the checks are comfortably green, including 100% green in the primary benchmarks, which I find is often the best measure we have of how this impacts code at runtime. And IIRC there's a bunch of Arcs in the query system. (Sometimes doc can do that too, but here that's very quiet.) Then debug is mixed but still comfortably green, also 100% green in primary.

Opt isn't trivially-fine, but I think it's ok. Lots of them are incr anyway, which is relatively rare with opt. And the one big outlier in icount shuffled its codegen schedule massively:

So with that I think the icounts are misleading, and its wall time result is still within reasonableness: +1.93% but that's below the significance threshold since it looks like that happens a ton for it:

Since this makes Deref simpler and thus changes the inliner cost estimates for something quite common, it seems entirely plausible that this would thus permute the opt results a whole bunch.

I think I might actually be more curious about the binary size changes. Dropping 126KiB off rustc_driver.so looks great, but then image and cargo get materially bigger in binary size for opt-full, which seems weird. I would have expected this to help drop size a bit by reducing the need for offsetting loads, but almost everything is bigger instead.

Any idea where that extra binary size is coming from?

@tgross35: There isn’t any significant change since the last perf run (https://perf.rust-lang.org/compare.html?start=b88076097751f7677b850b94b20faf5679fca321&end=1a76f3df0b6373e760df2514a5af2587f3e01aff&stat=instructions:u). But my local development environment is currently broken, and I’ll need some time to analyze the perf result.

Oh yeah that the wins definitely outweigh the losses here, no disagreement. I’m just wondering what makes clif such an outlier.

The cargo changes have to be inlining, maybe this just tips the scale for something commonly-called medium-sized function to be inlined.